Skip to content

feat(jsonrpc): add blockTimestamp to logs and receipts#6671

Open
0xbigapple wants to merge 4 commits intotronprotocol:developfrom
0xbigapple:feature/jsonrpc-timestamp
Open

feat(jsonrpc): add blockTimestamp to logs and receipts#6671
0xbigapple wants to merge 4 commits intotronprotocol:developfrom
0xbigapple:feature/jsonrpc-timestamp

Conversation

@0xbigapple
Copy link
Copy Markdown
Collaborator

@0xbigapple 0xbigapple commented Apr 9, 2026

What does this PR do?
Adds the blockTimestamp field to the log objects returned by JSON-RPC event and receipt query interfaces, aligning the TRON JSON-RPC implementation with the Ethereum execution-apis specification. close #6617

Specifically, it updates:

  1. LogFilterElement (used in eth_getLogs, eth_getFilterLogs, eth_getFilterChanges(about log/event filter)) to include blockTimestamp.
  2. TransactionLog within TransactionReceipt (used in eth_getTransactionReceipt, eth_getBlockReceipts) to include blockTimestamp.

The timestamp is extracted from the corresponding TransactionInfo's blockTimeStamp, divided by 1000 to convert to seconds, and returned as a hexadecimal string (e.g., "0x3e8").

Why are these changes required?
To maintain compatibility with the evolving Ethereum JSON-RPC API standards. Adding the block generation timestamp directly to the log objects enables developers and dApps to process event streams with precise time context without needing to perform secondary eth_getBlockByHash/Number queries, significantly reducing network overhead and improving client efficiency.

This PR has been tested by:

  • Unit Tests:
    • Added assertions in LogMatchExactlyTest.java to verify blockTimestamp in LogFilterElement.
    • Added assertions in TransactionReceiptTest.java to verify blockTimestamp in TransactionReceipt.TransactionLog.
  • Manual Testing: N/A

Follow up

Extra details

@github-actions github-actions bot requested a review from bladehan1 April 9, 2026 12:19
@halibobo1205 halibobo1205 added this to the GreatVoyage-v4.8.2 milestone Apr 10, 2026
xxo1shine
xxo1shine reviewed Apr 13, 2026
View reviewed changes
Comment thread framework/src/main/java/org/tron/core/services/jsonrpc/types/TransactionReceipt.java Outdated
waynercheung
waynercheung reviewed Apr 13, 2026
View reviewed changes
Comment thread framework/src/test/java/org/tron/core/services/jsonrpc/TransactionReceiptTest.java Outdated
waynercheung
waynercheung reviewed Apr 13, 2026
View reviewed changes
Comment thread framework/src/test/java/org/tron/core/jsonrpc/LogMatchExactlyTest.java
@0xbigapple 0xbigapple force-pushed the feature/jsonrpc-timestamp branch from 92d7b71 to b3c6ccb Compare April 14, 2026 05:12
bladehan1
bladehan1 reviewed Apr 14, 2026
View reviewed changes
Copy link
Copy Markdown
Collaborator

@bladehan1 bladehan1 left a comment •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See review, comments

Comment thread framework/src/main/java/org/tron/core/services/jsonrpc/TronJsonRpc.java Outdated
@waynercheung
Copy link
Copy Markdown
Collaborator

waynercheung commented Apr 15, 2026

[SHOULD] The implementation looks good and I’m comfortable approving it. One follow-up I’d still recommend is adding direct API-level coverage for eth_getFilterLogs and eth_getFilterChanges in JsonrpcServiceTest, so the test surface fully matches the public APIs listed in the PR scope.

@0xbigapple
Copy link
Copy Markdown
Collaborator Author

0xbigapple commented Apr 15, 2026

[SHOULD] The implementation looks good and I’m comfortable approving it. One follow-up I’d still recommend is adding direct API-level coverage for eth_getFilterLogs and eth_getFilterChanges in JsonrpcServiceTest, so the test surface fully matches the public APIs listed in the PR scope.

Thanks for the follow-up. Since eth_getFilterLogs and eth_getFilterChanges share the same underlying code path as this change, the positive-path test on eth_getLogs already covers the shared logic including blockTimestamp validation. Adding full API-level tests for those two endpoints is beyond the scope of this change, as they didn't have tests before this PR either. That said, I think it would be great to have a dedicated tracking issue to cover API-level tests for all JSON-RPC endpoints holistically, not just these two.

@lvs0075 lvs0075 requested a review from 317787106 April 16, 2026 09:20
317787106
317787106 reviewed Apr 17, 2026
View reviewed changes
Comment thread framework/src/main/java/org/tron/core/services/jsonrpc/TronJsonRpc.java Outdated
@waynercheung
Copy link
Copy Markdown
Collaborator

waynercheung commented Apr 17, 2026

That said, I think it would be great to have a dedicated tracking issue to cover API-level tests for all JSON-RPC endpoints holistically, not just these two.

@0xbigapple Thanks, that makes sense to me overall.

I agree this does not need to block the current PR. For eth_getFilterLogs, the existing eth_getLogs positive-path test gives reasonable confidence because they share the same query path. My only nuance is that eth_getFilterChanges does not fully share the same API flow, since it goes through filter creation / queueing / pop semantics, even though it does reuse the same LogFilterElement construction logic.

I’m fine treating that as follow-up rather than scope for this change. If you file a tracking issue for broader JSON-RPC API-level coverage, please link it here so we have a concrete follow-up item.

@0xbigapple
Copy link
Copy Markdown
Collaborator Author

0xbigapple commented Apr 17, 2026

That said, I think it would be great to have a dedicated tracking issue to cover API-level tests for all JSON-RPC endpoints holistically, not just these two.

@0xbigapple Thanks, that makes sense to me overall.

I agree this does not need to block the current PR. For eth_getFilterLogs, the existing eth_getLogs positive-path test gives reasonable confidence because they share the same query path. My only nuance is that eth_getFilterChanges does not fully share the same API flow, since it goes through filter creation / queueing / pop semantics, even though it does reuse the same LogFilterElement construction logic.

I’m fine treating that as follow-up rather than scope for this change. If you file a tracking issue for broader JSON-RPC API-level coverage, please link it here so we have a concrete follow-up item.

Thanks for the clarification on eth_getFilterChanges — you're right that the filter creation / queueing / pop flow is distinct from the direct query path, so sharing LogFilterElement construction isn't full coverage.

Agreed this is better tackled as a dedicated effort rather than squeezed into this PR. I don't have the bandwidth to open the tracking issue right away, but I'll circle back and file it when I do, and link it here.

@waynercheung
Copy link
Copy Markdown
Collaborator

waynercheung commented Apr 17, 2026

Agreed this is better tackled as a dedicated effort rather than squeezed into this PR. I don't have the bandwidth to open the tracking issue right away, but I'll circle back and file it when I do, and link it here.

Sounds good. Agree this can be handled as follow-up and does not need to block this PR. Please link the tracking issue here once it is filed.

wink-link
wink-link approved these changes Apr 17, 2026 •
edited
Loading
View reviewed changes
waynercheung
waynercheung approved these changes Apr 17, 2026
View reviewed changes
Copy link
Copy Markdown
Collaborator

@waynercheung waynercheung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@317787106 317787106 317787106 left review comments

@xxo1shine xxo1shine xxo1shine left review comments

@bladehan1 bladehan1 bladehan1 left review comments

@waynercheung waynercheung waynercheung approved these changes

+2 more reviewers

@warku123 warku123 warku123 left review comments

@wink-link wink-link wink-link approved these changes

Reviewers whose approvals may not affect merge requirements

At least 2 approving reviews are required to merge this pull request.

Assignees

@0xbigapple 0xbigapple

Labels

topic:json-rpc

Projects

None yet

Milestone

GreatVoyage-v4.8.2

Development

Successfully merging this pull request may close these issues.

[Feature] Add blockTimestamp to JSON-RPC log objects to improve efficiency

8 participants

@0xbigapple @waynercheung @317787106 @xxo1shine @warku123 @wink-link @bladehan1 @halibobo1205